点击“开发者技术前线”,选择“星标🔝”
在看|星标|留言, 真爱
作者:最有文化的码农
点击“开发者技术前线”,选择“星标🔝”
在看|星标|留言, 真爱
作者:最有文化的码农
Http基于TCP/IP协议的一种传输协议,如果承载TSL/SSL协议层之上便就成为了https。
http基于TCP/IP协议的一种传输协议,如果承载TSL/SSL协议层之上便就成为了https。
有关两者的详细比较和关联后面在介绍原理的时候会详细说明。
对于http我们接触最多,使用最多也就是缓存,通常所说的web缓存实际上更多的指的是http的缓存,当然还有浏览器本身自己的缓存机制。缓存的使用不当或者对http缓存机制的理解不深入就会导致很多问题,比如:我强制刷新了为毛加载的还是缓存数据?
至于为什么,我先不讲,先来了解下缓存机制和原理,知己知彼方可百战不殆。在解析每一种机制之前,我都习惯性联想分类。比如提到缓存体系,我们就应该想到缓存的存储,毕竟缓存也是数据。然后就是缓存的过期机制,毕竟任何缓存不可能持久存在,特么的爱情还能过期呢。最后,就是缓存的刷新,毕竟每个时间段的缓存内容是不一样的。
总结起来,就是三个方面:缓存的存储策略,缓存的过期策略,缓存的刷新策略。
缓存存储:
用来确定http的响应内容是否可以被客户端存储。
关键的属性Cache-Control,他包含的属性:
public:标记认证内容也可以被缓存。一般来说经过http认证的内容,是不会自动缓存的,但是加上这个就可以了。(response)
private:数据只能存储到私有的cache,对某个用户专用,不能共享(response)
no-cache:不建议缓存到客户端,但是还是可以缓存的。
4.max-age:缓存的时间,相对时间,从请求时间到过期时间的间隔,单位是秒。
5.no-store:不允许任何内容被缓存到客户端。
以上是几个常用的存储策略,坦白讲其实就是客户端或者服务端对http协议缓存的一种控制。
缓存过期:
他的作用就是什么时候该请求服务端重新捞取数据了。简单这样理解后,那么问题来了,我特么怎么知道什么时候该请求什么时候该从本地缓存拿数据?
这个问题吐槽到重点了,那就一起看看呗。
Cache-Control:private
Expires:当前时间+max-age
看到这里我们疑惑了,上面刚讲到cache-control里面有一个max-age。这个属性就是设置缓存的有效时间,换句话说,如果过了这个时间段就会去请求服务器。所以问题又来了,如果这两个同时设定了这不是搞事情吗?该听说的呢?别怕,cache-control里面的东西永远都是优先级高的,换句话说,如果max-age设置了,expires设置了也白搭。
缓存刷新:
其实说到这一块的时候,个人认为才说到重点。我们搞缓存是为了什么?此时脑海中应该立马想到一个字:快!
的确,在某种意义上来讲的确是快,比如我们经常会发现第二次打开同一个界面要比第一次大开快很多,数据感觉像是假的似的,一下子全部展现。其实这就是用了缓存,更有甚至连网都没有,数据竟然都能展现,这也是缓存。
好了,说了这么多废话,http缓存的刷新机制到底是怎样的呢?结合以上两点,其实我们应该心里有点谱了,没错就是你想的那样!
首先,客户端发现,艾玛,缓存到期了,赶紧去请求服务器吧。
服务器说:你捉急是没有用滴,我得慢慢来考察,第一,你真的过期了吗?第二,请求的内容真的有变化吗?
针对服务端的这两个疑惑,服务端是怎么做到的呢?
对于是否真的过期,客户端会给服务端一个标识last-modified-since,通过时间的对比去判断是否真的过期。
对于数据是否改变,客户端会带过来一个字段if-none-match,每一次服务端都会有一个对应Etag字段,对比两个字段的值去判断实体数据是否发生了变化从而决定要不要返回给客户端数据。
http请求是一个标准的客户端服务请求模式,也是常说的C/S结构:
说到这里还是得提一下,http是如何建立在TCP/IP协议之上的,TCP/IP协议是如何协调工作的。
第一步:地址解析,从url中解析协议名称,主机名,端口号和对应的页面地址。
第二步:封装http的请求数据包:这一步主要是封装自己的信息,比如在post请求时,我们会塞进一个data数据。
第三步:封装tcp包,建立连接:因为是基于tcp的协议,网络连接是tcp来完成的,必然要封装成tcp包,然后tcp再做自己工作,比如封装ip包,一层层往下传。
第四步:发送请求:数据整好了,连接也完事了,那就发送action了。
第五步:服务端响应:接受到请求,然后给出响应。
第六步:服务端关闭tcp的连接:一次通信完成之后,若conection的设置不是keep-live的话,服务端会自动关闭tcp的连接。
通过对以上http的了解,我们似乎并没有看到他的不足之处,但是有心的同学会发现,在说到tcp和ip的时候,提到tcp是为了尽量保证数据的完整性,这说明ip层会发生数据丢失的情况,而这种情况存在tcp层只是尽量并没有完全做到保证数据的完整性。这个问题会不会在http这层也出现呢?当然,很多东西是遗传的,包括缺陷。的确,在http这一层存在数据的不安全性,并且因为http是协议变的简单化,方便化,同时也带来了ip层没有的缺陷,比如我们的传输数据都是明文,一旦是明文就会出现一下问题:
内容可能被窃听!
内容可能被篡改!
没有身份验证可能会被冒充!
而以上的三种问题恰恰是http协议的不足。
http协议的所有传输内容都是明文,即便是自己加密了,但是加密的内容也依旧是明文,这就避免不了被窃听!
再者,http协议传输的过程中没有身份验证这一说,这样就不免半路杀出一个不明身份就行身份冒充!
最后,http协议传输的过程中也并没有进行数据完整性的校验,不免有些人在中途进行内容篡改!(MITM)
总之以上存在缺陷成就了一批网络黑客,也成就了一批猖狂的病毒!
针对http的协议缺陷,正义的我们是不会视而不见的,因此https诞生了!说到这,请鼓掌!
通过上图我们看到了新的玩意,TLS和SSL,有关这两个下面的原理会讲道。
针对于以上缺陷,https增加了两种技术:加密技术和身份验证。
加密技术:
有关加密的具体方法我之前有讲过,这里不再多一一介绍。主要用到以DES为代表的对称加密算法和以RSA为代表的非对称加密算法。
对称加密算法一般很难破解,但是不太好保管,安全性也不是很高,为啥呢?因为客户端和服务端拿到的密钥是一样的,不可能每次都把key给改了,而不改的话,一直用同一个key的话也会存在安全隐患。
因此https的加密的方式采取的是混合方式。交换密钥的时候采取非对称的,建立通信交换报文的时候采取对称加密的方法。
身份验证技术:
就是用公钥生成可信赖的证书。因为非对称加密存在一个问题就是没法验证拿到的公钥就是服务端公开的公钥。
为了解决以上问题,CA应用而生(Certifity Authority),数字证书认证机构。盗一张图:
这张图一看便懂,ca的信息我们也能看到有哪些。
CA的使用流程:
相关人去CA机构进行公钥申请。
CA机构会验证申请者的信息真实性,合法性。
通过审核后,CA机构会做数字签名,给其证书。证书里面包含申请者的信息,数字签名后的公钥,有效时间和签名。
客户端https建立连接的时候像服务端要证书。
读取证书信息,拿公钥进行解密校验。
客户端会内置CA的信息,如果不存在或者信息不对,证明CA非法。
备注:遵循私钥永远都是服务端一方掌握。
协议实现:
TLS,记录协议负责在传输连接上交换底层信息,并加以配置加密。每一条tls记录包含标头和消息内容两部分。标头包含类型,版本和长度。咋一看和报文数据很像。
TLS有四个核心协议:
握手协议:单项最常见,验证服务端身份。双向验证,客户端和服务端都需要验证。
密钥变更协议
应用协议
警报协议
协议使用:
通过SSLContext来指定你选择的协议:
2.通过X509TrustManager检查证书:
备注:这里明白着就是跳过证书的检查了。如果不跳过会是怎样?
3.再者就是客户端读取证书然后调用:
写到上面代码,我记忆深刻,之前在做浏览器证书校验的时候,hostnameverify这一步一直过不了,原因是我们服务端证书的白名单也添加我们的hostname。
当然,你可以说不设置不就可以了吗?答案是不可以,因为你不重写HostnameVerify的verfiy方法,他默认所有返回都是false。这样就悲剧了。解决的方案有两种,第一种加白名单,第二种客户端跳过验证,例如:
扫码加我微信进群,内推和技术交流,大佬们零距离